System and method to manage the distribution of services software in a distributed network

ABSTRACT

A system and method for composing, configuring, deploying, and managing services in a data processing system and data processing system network. This system provides deployment domains to define a logical set of business services that have similar requirements for an application infrastructure. A deployment domain is created, and a graphical user interface allows a user to compose, configure, deploy, and manage services within the deployment domain and associated hosts using a drag-and-drop interface. A system and method for distributing and updating services software in the network and configuring heterogeneous underlying web services hosting platforms is claimed.

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] The present application is a continuation-in-part of U.S. patentapplication Ser. No. 10/350,164, filed 23 Jan. 2003, for “System AndMethod For Composing, Configuring, Deploying, And Managing ServicesUsing A Graphical User Interface,” which is hereby incorporated byreference, and claims the benefit of the filing date thereof.

[0002] This application also shares at least some common text andfigures with, but is otherwise unrelated to, commonly assigned U.S.patent application Ser. No. ______ for “System And Method For ProvidingA Plug-And-Play Architecture For Integrating Infrastructure ServicesWith Business Service Implementations,” Ser. No. ______ for “System AndMethod For Automated Code Generation Using Language Neutral SoftwareCode,” and Ser. No. ______ for “System And Method For CustomizingInfrastructure Services For Use In Network Services,” all filedconcurrently herewith, and which are hereby incorporated by reference.

TECHNICAL FIELD OF THE INVENTION

[0003] The present invention is directed, in general, to data processingsystem services management.

BACKGROUND OF THE INVENTION

[0004] In the area of conventional business service development, thereare, in general, three major roles, each role having specific tools toaddress its needs.

[0005] Application architects are primarily concerned with defining thecontracts of the business services to meet the business requirements. Anapplication contract consists of one or more interface definitions,reflecting the right level of interface granularity and service behaviorsuch as operations exposed and their inputs and outputs.

[0006] An important aspect of the architect's task here is to ensurethat existing interface types are reused so that multiple interfacetypes and messages are not reinvented to fulfill similar requirements.

[0007] Once the correct interfaces have been defined, the applicationdevelopers are ready to implement those interfaces. This often involveswriting code that implements business logic. The developers also have tobe able to unit test the code that they have just written.

[0008] Finally, once the code has been developed, it can be given to thesystem administrators for configuration, deployment and management. Theycan then configure the runtime execution environment for the newlydeveloped service and deploy the application. Once deployed, theapplication can then be managed through the means available in theenvironment.

[0009] In the conventional development model, the applications aredeveloped from scratch. This allows the users to perform top-down designand leverage the full capabilities of the available technologies sinceno baggage needs to be carried from the past.

[0010] Currently, there are 5 major phases of the lifecycle of thebusiness services. In the model phase, the application architects designthe interfaces for the business services to be developed. Once theinterfaces have been designed, the business logic is developed by thedevelopers of the system. The system architects then configure theruntime for the business service and the administrators then deploy andmanage the business services.

[0011] In many cases, the business services already exist but are notmanageable. These services may be either 3rd party off-the-shelf (COTS)applications or custom applications developed in-house or by systemintegrators.

[0012] This style of development is bottom-up development where theinterfaces are actually constructed based on existing applications. Thearchitects first use introspection to reverse engineer metadata from theexisting applications. These applications may exist in one of manysupported technologies such as Java classes, CORBA, EJB's, existing webservices or COTS packages such as SAP or Siebel. Introspection wouldresult in one-to-one interface generation. However, in real world, theseinterfaces may need to be refactored. Refactoring involves eithersuppressing some of the operation in an interface, creating brand newones, combining two or more interfaces (contract aggregation) orsplitting a contract into two or more contracts (contractdissemination).

[0013] It should be noted that the existing applications could also beweb services. The process should however be no different than that for3rd party COTS or custom applications supporting a particulartechnology.

[0014] Business logic generally does not change in nature. However, theunderlying technologies are changing very rapidly. For example, thereare a number of new standards that are being developed to addressvarious aspects of distributed business services. Many standards do nothave any sort of industry consensus and many areas have competingstandards. However, the applications have to be developed today.Typically, the business services are written to provide all the othernecessary functionality, such as security and others (applicationinfrastructure services) that do not actually contribute to the businessbehavior itself. As the standards and technologies for these otherservices (application infrastructure services) evolve, the businessservices have to be modified and enhanced in order to take advantage ofthem. Furthermore, in the current state of the art, the configurationand deployment of these services is specific to a particular underlyingenvironment and the underlying products.

[0015] There is, therefore, a need in the art for an improved system andmethod for distributing updated, modified, and enhanced services in adistributed network.

SUMMARY OF THE INVENTION

[0016] To address the above-discussed deficiencies of the prior art, andto provide generally improved systems and methods, it is a primaryobject of the present invention to provide an improved system and methodfor business services development and management in a data processingsystem and data processing system network.

[0017] The preferred embodiment provides a system and method forcomposing, configuring, deploying, and managing services in a dataprocessing system and data processing system network. This systemprovides deployment domains to define a logical set of business servicesthat have similar requirements for an application infrastructure. Adeployment domain is created, and a graphical user interface allows auser to compose, configure, deploy, and manage services within thedeployment domain and associated hosts using a drag-and-drop interface.A system and method for distributing and updating services software inthe network and configuring heterogeneous underlying web serviceshosting platforms is claimed.

[0018] The foregoing has outlined rather broadly the features andtechnical advantages of the present invention so that those skilled inthe art may better understand the detailed description of the inventionthat follows. Additional features and advantages of the invention willbe described hereinafter that form the subject of the claims of theinvention. Those skilled in the art will appreciate that they mayreadily use the conception and the specific embodiment disclosed as abasis for modifying or designing other structures for carrying out thesame purposes of the present invention. Those skilled in the art willalso realize that such equivalent constructions do not depart from thespirit and scope of the invention in its broadest form.

[0019] Before undertaking the DETAILED DESCRIPTION OF THE INVENTIONbelow, it may be advantageous to set forth definitions of certain wordsor phrases used throughout this patent document: the terms “include” and“comprise,” as well as derivatives thereof, mean inclusion withoutlimitation; the term “or” is inclusive, meaning and/or; the phrases“associated with” and “associated therewith,” as well as derivativesthereof, may mean to include, be included within, interconnect with,contain, be contained within, connect to or with, couple to or with, becommunicable with, cooperate with, interleave, juxtapose, be proximateto, be bound to or with, have, have a property of, or the like; and theterm “controller” means any device, system or part thereof that controlsat least one operation, whether such a device is implemented inhardware, firmware, software or some combination of at least two of thesame. It should be noted that the functionality associated with anyparticular controller may be centralized or distributed, whether locallyor remotely. Definitions for certain words and phrases are providedthroughout this patent document, and those of ordinary skill in the artwill understand that such definitions apply in many, if not most,instances to prior as well as future uses of such defined words andphrases.

BRIEF DESCRIPTION OF THE DRAWINGS

[0020] For a more complete understanding of the present invention, andthe advantages thereof, reference is now made to the followingdescriptions taken in conjunction with the accompanying drawings,wherein like numbers designate like objects, and in which:

[0021]FIG. 1 depicts a block diagram of the relationships betweenservice layers in accordance with a preferred embodiment of the presentinvention;

[0022]FIG. 2 depicts a block diagram relating a development anddeployment lifecycle with data objects and service objects in accordancewith a preferred embodiment of the present invention;

[0023]FIG. 3 depicts a block diagram of a runtime environment inaccordance with a preferred embodiment of the present invention;

[0024]FIG. 4 illustrates a federated metadata storage and access systemin accordance with a preferred embodiment of the present invention;

[0025]FIG. 5 depicts a virtual composition environment in accordancewith a preferred embodiment of the present invention;

[0026]FIG. 6 depicts a block diagram of a virtual container accordancewith a preferred embodiment of the present invention;

[0027]FIG. 7 depicts a flowchart of a process in accordance with apreferred embodiment of the present invention; and

[0028]FIG. 8 depicts a flowchart of a process in accordance with apreferred embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0029]FIGS. 1 through 8, discussed below, and the various embodimentsused to describe the principles of the present invention in this patentdocument are by way of illustration only and should not be construed inany way to limit the scope of the invention. Those skilled in the artwill understand that the principles of the present invention may beimplemented in any suitably arranged device. The numerous innovativeteachings of the present application will be described with particularreference to the presently preferred embodiment.

[0030] Definitions: Following are short definitions of the usualmeanings of some of the technical terms which are used in the presentapplication. (However, those of ordinary skill will recognize whetherthe context requires a different meaning.) Additional definitions can befound in the standard technical dictionaries and journals.

[0031] Business Service Contract—A business service contract describesthe business service exposed. This normally contains information such asoperations provided by the service, their inputs and outputs.

[0032] Business Service Implementation—A business service implementationis the software code required strictly to implement the above mentionedbusiness behavior. This does not include other capabilities such asproviding security or managing transactions.

[0033] Application Infrastructure Services—Application InfrastructureServices are all those services that themselves do not contribute to thebusiness behavior, however they are necessary for the correct operationof the business service. These services can be added, removed orreplaced without changing the business behavior of the business service.

[0034] Virtual Container—A virtual container couples a business serviceimplementation with one or more application infrastructure services andprovides the definition for a complete business service. This definitionexists in metadata and contains all the metadata that customizes thespecific usage of application infrastructure services inside the saidvirtual container.

[0035] Physical Business Service—A physical business service is theplatform specific programming code that can be generated according tothe previously discussed definition of the virtual container. This codecan then be compiled and deployed in the underlying platform specificmanner.

[0036] Web Services will soon be providing complex and mission criticalservices to business partners and internal customers by providing aviable alternative to most application integration scenarios.

[0037] The disclosed embodiments provide a system and method forcomposing, configuring, deploying, and managing services in a dataprocessing system and data processing system network. This systemprovides deployment domains to define a logical set of business servicesthat have similar requirements for an application infrastructure. Adeployment domain is created, and a graphical user interface allows auser to compose, configure, deploy, and manage services within thedeployment domain and associated hosts using a drag-and-drop interface.A system and method for distributing and updating services software inthe network and configuring heterogeneous underlying web serviceshosting platforms is claimed.

[0038] The metadata is managed by a federated metamodel system. A visualcomposition environment allows composition of a virtual container thatcouples the business service implementation in question with theapplication level infrastructure services that it needs. The codegenerators can then generate platform specific code for the virtualcontainer. All this can be packaged for easy shipment. The packagedbusiness services can then be easily deployed on any of the machinesavailable to the system.

[0039] The disclosed embodiments include a method and system fordescribing the underlying application services infrastructure, a virtualexecution environment for business services implementations and a systemto integrate the two in a loosely coupled way through metadata so thatthe two can evolve independently and still stay compatible.

[0040] In the preferred embodiment, a deployment domain is created, anda graphical user interface allows a user to compose, configure, deploy,and manage services within the deployment domain and associated hostsusing a drag-and-drop interface.

[0041] Furthermore, once the metadata has been defined, it becomes veryeasy to provide user interface based tools that allow construction of abusiness service by visually composing an execution environment for thealready-built business service implementation. The implementation itselfdoes not know about the kind of the environment in which it will bedeployed. Because of this, the implementation can be deployed inexecution environments that provide vastly different quality of service.

[0042] The preferred embodiment includes the following features:

[0043] The ability to build business service implementations without anyknowledge of the underlying infrastructure environment.

[0044] The ability to describe a deployment environment without anyknowledge of what kind of business services will be deployed in it.

[0045] The ability to enhance an infrastructure environment by providingcustom application infrastructure services. These services, byimplementing abstract interfaces, can be plugged into any supportedinfrastructure environment. These application infrastructure servicesprovide discrete non-business related services and do not make anyassumptions about who is going to use them and how will they be used.

[0046] The ability to construct a virtual container, once the businessservice implementations have been developed, that integrates them withpreexisting infrastructure services and allows for better management.

[0047] The ability to describe various components and provideplug-and-play development and deployment using a metadata foundation.

[0048]FIG. 1 illustrates these objectives further. A managementframework 120 hides the underlying application server environment 140from the business service implementation 110 and augments the underlyingenvironment by providing the ability to add and integrate applicationinfrastructure services. Further, an implementation framework 130 can beprovided that even provides implementation services 150 such as adatabase management system.

[0049] The preferred embodiment provides a platform that provides alevel of abstraction, much higher than the one that is provided byapplication servers and other web services platforms currentlyavailable. This platform brings the development, configuration,deployment and management capabilities to the business services.

[0050] The lifecycle shown in FIG. 2 relates to either doing newdevelopment or introspecting existing application for the purpose ofconverting them into managed business services. As described above, thelifecycle includes the model or introspection phase 205, in which theapplication architects design the interfaces for the business servicesto be developed or introspect an existing service. In the case of newdevelopment, once the interfaces have been designed, the skeleton ofbusiness service implementation can be generated and then developed bythe developers. In case of existing service, once the existing servicehas been introspected, a gateway implementation can be automaticallygenerated 210. The system architects then configure 215 the runtime forthe business service. Finally, the administrators then deploy 220 andmanage 225 the business services.

[0051] One disclosed feature of the preferred embodiment is a federatedmeta-model 230 that stores and provides access to the metadatadescribing the business services themselves and their infrastructure.This metadata describes the interface of the business service itself,the metadata about those infrastructure services, and the metadata aboutthe virtual container that couples a business service implementationwith one or more infrastructure services along with their uniquelycustomized properties.

[0052] The preferred embodiment is designed to expose a level ofabstraction higher than those provided by industry standards 240. Thestandards and technologies in the web services area are changing veryrapidly. As a result, the business services that leverage thosestandards run the risk of becoming outdated very quickly. The preferredembodiment exposes a higher level interface that can be generated by themetadata itself. This results in more stable and longer-lastingapplications.

[0053] The preferred embodiment provides the horizontal platform thatcan be used to build the vertical solutions that are more specific toindustries in the form of industry specific templates 250. Thesesolutions do not have to be complete themselves. In fact, most likelythese solutions will be partial solutions designed to be extended forparticular business problems.

[0054] Once the business services have been created, they can beorchestrated 260 using business service orchestration tools. Theseorchestrations themselves can be manifested as web services, thusforming a recursive relationship.

[0055]FIG. 3 describes the runtime environment for which the businessservices are configured and in which they are deployed. Thisarchitecture is described here at the logical level and can have one ormore physical manifestations, in accordance with the disclosed orclaimed embodiments.

[0056] A deployment domain 300 is a mechanism for partitioning a largeIT environment into smaller logical clusters of machines andapplications so that these different clusters can be configureddifferently from each other. In this case, these deployment domainsserve to logically separate environments with different requirementsdomain. For example, there may be a deployment domain called internalapplications. This domain may be configured with a specific securityservice. Another domain may be for business partners and may beconfigured with a different kind of security service. Additionally, thisdomain may also be configured with a management service, e.g., to billthe users for usage of the business service. The deployment domainserves to define the scope of the infrastructure services that it iscomposed of and the business services that are deployed in it.

[0057] The deployment domain defines the logical boundaries and scope ofthe infrastructure and business services within it. It is a logicalpartition of a large computing environment which consists of manyphysical machines. The metadata data related to the deployment domaindefines that logical partition.

[0058] One or more physical machines can be configured for a deploymentdomain and one or more application infrastructure services can be madepart of the fabric that is a deployment domain. Each server machine,called a host, that is configured to participate in one or moredeployment domains will contain a core software service.

[0059] The metadata that describes a host can include such items as hostname, host's IP address, the core directory path on the host for theapplication, etc.

[0060] Since there is a many-to-many relationship between the hosts anddeployment domains, a list of hosts can exist independently of thedeployment domains. When a host is configured for a deployment domain,it has to be able to run all of the business services deployed in thatdomain. The application infrastructure services do not have to run onthe host because they can themselves be remote.

[0061] An application infrastructure service is defined as a servicethat provides a discrete non-business level service. Some examples ofinfrastructure services are security services, transaction services,service monitoring, load balancing, fault tolerance, and messagingservice. An infrastructure may also provide some other services such asreliable delivery or asynchronous messaging. These services can also bemuch higher level; services such as accounting & billing services,service level agreement management services and user profile managementservices.

[0062] The best way to characterize an application infrastructureservice or differentiate it from a business service is that businessservice in itself performs a business function, such as procurement or ahuman resource system. In contrast, an infrastructure service providessecondary functionality that is not part of the business functionsitself.

[0063] The metadata of an infrastructure service consists of propertysheets with each property sheet containing one or more relatedproperties. For example, a security service may contain five sheets forgeneral properties, authentication, authorization, message integrity,and message confidentiality. Each sheet contains properties that allowcustomization of the underlying infrastructure service for this specificuse. Since these properties are specific to the underlying service,their interpretation is left completely up to the service itself and itsplugin. Furthermore, since the property values are specific to thespecific usage of this service, these properties need only be definedonce a virtual service container is configured with this service.

[0064] Once an infrastructure service has been written or purchased, ithas to be made part of one or more deployment domains so that it can beused. This is accomplished by defining an abstract plugin interface.This interface allows the deployment management tools and runtimesoftware to plugin an infrastructure service into the deployment domainand allows the service to be used at runtime. The tools that allow theuser to visually configure the virtual service container may allowmechanisms to “drag” the infrastructure service and “drop” it on thevirtual service container on a canvass. The tools can at this timepresent the required set of properties to be defined for the service forthis particular container. This is accomplished by requesting the pluginto provide its customizable property sheets so that they can be filled.

[0065] At runtime, the virtual container receives the requests sent tothe business service and invokes plugs for all the applicationinfrastructure services configured for this container. The plugin canthen retrieve the metadata and use it to perform the work. If the actualinfrastructure service is implemented as a set of libraries, then theplugin can invoke those libraries or if it represents a remote servicethen it can communicate with that remote service in a manner that isspecific to that infrastructure service. In any case, the runtime is notaware of the details of the operation—it simply invokes the plugin andpasses it the runtime invocation-related data.

[0066] Each infrastructure service is therefore required to implementthe plugin interface as a precondition to it becoming part of aninfrastructure. An infrastructure service may provide different pluginsfor different deployment domains. The location and other necessaryinformation required to load the plugin is part of the metadata of theinfrastructure service.

[0067] A business service implementation is an implementation of thebusiness behavior that a service is expected to provide. This behaviorshould be implementable in a manner independent of how it is accessed.For example, it should be possible to implement the business logic for aprocurement service without being specific to Jave Platform 2 EnterpriseEdition (J2EE)-based access or Microsoft .NET based access. However,once the service has been constructed, it may be deployed in a virtualcontainer 320 that is specific to the underlying platform. This virtualcontainer then decouples the service implementation from theinfrastructure in which it is deployed.

[0068] This virtual service container 320 is conceptually similar to aJ2EE container to the extent in that it provides the several neededservices such as transaction and database management. However, unlikeJ2EE like containers, these services are not fixed but can be added,removed and updated. The virtual container 320 of the preferredembodiment, is a higher level concept. It views an environment as acollection of discrete higher level services and recognizes the need forbusiness services to be integrated with those higher level services. Itlimits its scope to the infrastructure level services and does notprovide those services that are needed for implementing the businesslogic, such as database management.

[0069] The container is called “virtual” because it itself is a platformindependent definition rather than a physical implementation. It isdescribed in terms of metadata. The metadata for the container describesthe business service implementation that is it hosting. This service wasbuilt using the development tools and its definition is part of thedevelopment metadata. In an integrated system of tools, the deploymenttool may retrieve this definition from the development metadatarepository.

[0070] The metadata for the container also describes one or moreapplication infrastructure services required by the virtual container.When a virtual container is created, it is created for a particulardeployment domain. This deployment domain is already preconfigured withone or more infrastructure-level services. The deployment engineer canselect from those infrastructure services and integrate them into thecontainer using visual mechanisms such as dragging and dropping them onthe container. At this time, the tools may invoke the plugin and bringup the set of properties necessary to correctly use theinfrastructure-level service.

[0071] Once the virtual container has been defined, there is enoughmetadata to generate a physical implementation of the virtual container,build it, package it and transfer the required binaries to the host.Once this is done, the business service is ready to be deployed andused. When the code is generated, it is generated according to somepre-defined mappings of the metadata to the underlying platform. So forexample, the physical implementation for .NET platform may be quitedifferent from the physical implementation for J2EE. These mappingsdefine what elements of the metadata generate what kind of code for theunderlying platform.

[0072] Many underlying platforms either need to add software code thatis specific to them or require certain information in variousconfiguration files for the applications to function properly. Forexample, an application infrastructure service using microsoft'simplementation of WS-Security specification requires certain informationto be placed into the .NET specific configuration files. Also, someapplication infrastructure services may need to insert specificprogramming code in the generated code. For example, a load balancingservice may need to insert specific programming code in the generatedcontainer code as well as the generated client proxy to properly exploitits capabilities. For this reason, the code generators involve theapplication infrastructure service plugs in the code generation process.When code generator starts, it also loads the plugs for theinfrastructure services being used by the container. All code to begenerated, whether it is language code or configuration code isrepresented in XML. The code generator first creates XML documents forall the code that it wants to generate. It then invokes theinfrastructure service plugs and provides them an opportunity to addcode specific to them by passing the XML documents representing the codeto be generated. Once all the plugs have added their code, the codegenerator converts the XML documents back into either language specificcode or configuration code, as necessary. This way, the code generationprocess can be kept completely independent of a particularinfrastructure service while still allowing them to customize thegenerated code.

[0073] The separation between the business service implementation andthe underlying environment provides two benefits. First, it allows theunderlying application infrastructure and the business serviceimplementation itself to evolve independent of each other. Secondly,this allows the physical manifestation of the hosted service to leveragefully the capabilities offered by various infrastructures. This isexplained in more detailed below, but simply put it means that thevirtual container 320, through metadata 330 and visual tools, can bevisually composed to integrate one or more services offered by theunderlying infrastructure. Since this integration is performed throughthe virtual container and at configuration time, it does not become partof the service implementation itself. The same procurement service canthen be configured and deployed in two different deployment domainsproviding different levels of service.

[0074] Once the container has been configured and its software code hasbeen generated and built, a package can be created that includes all thenecessary platform specific binary assemblies required for this service.This package is then placed in a master vault. At this point, a visualdeployment tool can provide some mechanism such as drag-and-drop todeploy this business service on any machine that is part of thedeployment domain. If a host is then dragged and dropped on the virtualcontainer, its package is collected from the master vault and broughtover to the machine being dragged and dropped. This package is thenopened up and its contents are extracted. These contents are thenconfigured in a manner that is specific to the underlying platform.

[0075] The actual addressable and accessible service is then provided bythe physical form of the virtual container 320 which can be specific tothe underlying environment.

[0076] The traditional definition of management services tools 310 arenetwork managers. The management services and tools described here havemore application level context than the system level context. Someexamples of management tools are business service monitoring tools,service level agreement (SLA) managament tools, fault tolerance tools,application event handling, billing and accounting services or userprofile management.

[0077] Various application infrastructure services may provide their ownmanagement tools that will use the data collected by their plugins.

[0078] The most fundamental and core capability of this architecture isthe metadata 330. The metadata described here is logical metadata.Logically, each deployment domain 300 has its own instance of metadata330. This metadata describes the deployment domain itself in terms ofthe infrastructure services that it is able to offer and the virtualservice containers 320 that are deployed in it.

[0079] As a general rule, the exact form that the metadata is stored inis not important. The platform can choose an XML format, a relationaldatabase or some binary form.

[0080]FIG. 4 illustrates a federated metadata storage and access systemwith various possible clients of the metadata. The development toolswill require metadata that describes the team development environmentand will allow sharing of development artifacts. One exemplaryimplementation of the metadata architecture is illustrated below.

[0081] The metadata has been described above as a part of otherelements. It is useful to note that the two kinds of metadata that arerelevant here are configuration/deployment metadata and operationalmetadata.

[0082] The configuration/deployment metadata is used by theconfiguration and deployment tools as well as by the runtime system.This data will not change often but will rather be accessed concurrentlyby large number of users. A configuration metadata server shouldpreferably offer extensive caching features where the data is handed outwith a time-to-live parameter indicating how long the client can use thedata before being required to refresh it.

[0083] Operational metadata is used by one or more infrastructureservices such as a monitoring service, load balancing service, andfault-tolerance service. This data tends to change very frequently andthe tools that present this data, for viewing and analysis, may berequired to refresh based on user preferences.

[0084] The following is an exemplary case use in accordance with thepreferred embodiment. Here, we look at a typical use case scenario of alarge bank that serves consumer loan market. The bank has a largeinternal IT organization, responsible for delivering the businessservices to its users. The IT organization has to overcome thechallenges of building applications that will survive the changingtechnology. Furthermore, the enterprise considers the conformance ofindustry standards as its strategic goal.

[0085] The two initial applications that have been identified havedifferent needs. The first application is an Online Loan ApprovalSystem. Although the logic for credit-approval already exists in theform of many small systems, the bank wants to build a new system thatuses that logic but re-implements it in a more consolidated and scalablemanner. Previously, the bank employed a large loan approval departmentthat received the loan requests either through fax or telephone and usedthese multiple systems to score the applicant's credit history and makethe loan decisions. However, the bank wants to make this systemavailable online so that the applicant's could themselves apply for theloan. In addition to its potential clients, the bank may also decidelater on to make this system available to its smaller business partnersto get credit history of clients and to provide services such as creditrisk scoring. For those services, the bank may charge those businesspartners on a per-transaction basis.

[0086] The second system is an application, called Customer ServiceOnline system, that will allow bank's consumer loan clients to get thestatus of their accounts, directly without going through customerservice. This information already exists in a legacy J2EE system that isdeployed in the internal secure network. The bank wants to build afront-end web service to this system.

[0087] In order to meet its strategic technical objectives, the bank hasstandardized on toolkit in accordance with the preferred embodiment. Thebank also has a well-structured group that runs its data centers. Thedata center has system architects and system administrators whocollectively run the managed environment for all the bank'sapplications.

[0088] As is with any system, the normal steps of requirements gatheringand requirements analysis are performed. These steps are no differentthan any other application development project. However, once therequirements have been analyzed, the application architect willtransform the requirement for the Online Loan Approval System into abusiness interface. This business interface becomes the contract thathas to be implemented. The logic that implements this business interfaceis termed as the business logic that has to be developed.

[0089] The application architects use a off-the-shelf modeling tool tomodel the service contract. This contract identifies the operations(business functions) that the service exposes, defines a type systemthat defines the data required as inputs or is returned as outputs bythose operations. This business interface is critical data because itdefines the Contract between this business service and its users. Oncethe application architects have stabilized the business contract, theyextract contract information from the modeling tools and generatemetadata in a metadata repository, in accordance with the preferredembodiment.

[0090] The development team then takes this business contract andconducts a detailed design and develops the business logic. Thedevelopment team decides to use C# as the development language and theimplementation is developed as C# assembly.

[0091] The development team only focuses on implementing the businesslogic as required by the business contract. They do not address otherkey issues such as security, billing or scalability. Their efforts arestrictly focused on building one or more assemblies that implement thebusiness logic.

[0092] Once the implementation has been built and tested in stand-alonemode, an implementation package is created that contains the necessarymetadata and DLLs and is handed over to the data center that isresponsible for deploying and managing bank's applications.

[0093] The customer service system presents a different scenario thanthe first one. The bank really does not want to change the exitingsystem. The system works well and already has all the necessaryfunctions required to fulfill the task. However, this system waspurchased by the bank from a 3rd party and provides no way for bank toexpose it to external users and is not manageable.

[0094] The application architects have decided to use a system inaccordance with the preferred embodiment to build a front-end gatewayservice that will expose the functionality of this system to theexternal users and will conform to the strategic goals of the bank inbeing standards compliant and be manageable.

[0095] This process is very simple. The introspection capabilities ofthe preferred embodiment are used to analyze the J2EE interfaces exposedby the existing applications. From these, then one or more functions areselected and system then automatically generates the required metadata,populates the metadata repository and then generates a gatewayimplementation that can delegate requests to the existing system. As inthe previous case, this gateway implementation is then packaged in JARfiles and an implementation package is created. This implementationpackage is then handed over to the data center that is responsible forconfiguring, deploying and managing bank's applications.

[0096] Once the data center receives an implementation package, it isready to configure the service. It is assumed that by this time theminimal metadata that describes the service interface has been definedin the metadata repository.

[0097] The data center already has several different deployment domainsconfigured. The data center also uses several infrastructure servicessuch as Security. For some of its infrastructure services, the vendorsprovided toolkit-compatible plug-ins and for others the data centerwrote its own. In either case, those infrastructure services areproperly configured for the preferred embodiment and fit in itsplug-and-play architecture.

[0098] Configuring a business service involves several different stepsthat allow a business service implementation to be transformed into amanaged and hosted web service.

[0099] The business service implementation provided to the data centeris an implementation package that contains one or more DLLs or JAR filesthat implement the business behavior. These implementations lack theappropriate environment required to make the business serviceaddressable and hostable and they also lack the necessary infrastructurecapabilities such as security.

[0100] The first step that the system architects do is to define avirtual container. This virtual container extends the metadatadescribing the service contract with metadata relating to the desiredinfrastructure services. This metadata will be used later on to create aphysical web service that will provide a proper execution environmentfor the business logic implemented by the developers and will providethe flexible management environment required by the data center toperform its functions.

[0101] During this process, the system architects also decide whatinfrastructure level capabilities (security, transactions, etc.) arerequired for this business service. They then use the drag-and-dropfacilities available in the visual composition environment of thepreferred embodiment to create this container. As new infrastructureservices are dragged onto the virtual container, these infrastructureservices plugs are invoked by the graphical environment and at thistime, these plugs populate the metadata with a set of properties thatthey would like to be customized. The graphical environment thenpresents those properties in a property editor and lets the systemarchitect provide unique values of those properties. They can alsocustomize the container itself by setting its logging levels as well aschoose the correct QoS parameters such as various delivery modes.

[0102] Once the virtual container has been configured, the systemarchitects can select the target platform for this web service. Forexample, if the business implementation is written in Java, then thepotential target platforms can be any of the J2EE environments supportedby the installation. Alternatively, if the implementation was providedin DLLs, then the target platform can be Microsoft's .NET environment.

[0103] Once the target platform has been selected, the composer tool cangenerate the code necessary for a web service that can be physicallydeployed and managed and then build that code along with the providedimplementation into an executable. The composer then creates adeployment package that contains all the necessary DLLs or the JAR filesrequired for deployment.

[0104] This package is then automatically placed in a master vault thatis managed by the system of the preferred embodiment. All machines thatare configured in the data center have an agent service running on them.These agents cooperate with each other to transfer packages in and outof the master vault and configure particular underlying target platformsfor business services.

[0105] Once a deployable package has been created for a web service, thecomposer tool can be used to drag different hosts on a business service.This drag-and-drop operation triggers the actual deployment process.

[0106] When a host is dragged on a business service, the SOA Agentrunning on that host retrieves the deployment package from the mastervault, unpackages it on that machine, performs the steps necessary toconfigure the underlying environment and makes the web serviceaddressable.

[0107] A web service can be undeployed from a host by selecting thathost in composer tool and simply deleting it from there. This results inall traces of that package being removed from the machine.

[0108] One a service has been deployed, it can be easily managed.Whenever, a request is sent to that service, the physical containerprovided by the runtime environment receives it. The runtime environmentthen executes all the necessary infrastructure services configured forthis container and then invokes the business implementation provided bythe user. When it gets the response from the business serviceimplementation, it re-invokes any necessary infrastructure services andsends the response back to the caller.

[0109] As the technology changes, the infrastructure services canchange. The system architects can use the composer tool to slowlytransition the deployed business services from an old or obsolete moduleto a new module by simply removing the old plug from the businessservice and using drag-and-drop to configure the business service withnew plug. The preferred embodiment automatically removes older DLLs orJARs from the physically deployed services and copies the new ones forthe new plug. The business services adjust to the new infra-structureservice without the typical need for interruption and modification.

[0110] To continue the bank example, after the Online Loan Approvalservice has been deployed, the bank decides to make that serviceavailable to its business partners for a price. An internalinfrastructure level billing service is developed (along with itstoolkit compatible plug) and configured. The system architects simpledrag this infrastructure service on the Online Loan Approval service,without modifying the business implementation or bringing the servicedown. The preferred embodiment automatically modifies the metadata,reconfigures the deployed services and the runtime environment startsusing this new infrastructure service when requests are sent to thebusiness service.

[0111] One specific feature of the preferred embodiment is a visualcomposition environment. The preferred embodiment uses visual tools togenerate metadata. These tools can present the core metadata in a treestructure as shown in FIG. 5.

[0112]FIG. 5 shows an exemplary user interface 500 for a visualcomposition environment in accordance with the preferred embodiment. GUIinterface 500 is divided into multiple areas, including availableobjects area 510, active object identifier 540, related objects area520, and properties area 530.

[0113] Available objects area 510 shows all objects that are availableto be configured or deployed, including hosts, infrastructure services,service implementations, and deployment domains. The folder named“hosts” contains the list of all available hosts in the entire managedspace. The information that is visible for each host in this list can besuch as the name of the server and its machine address.

[0114] The folder named “infrastructure services” contains a list of allavailable infrastructure services. This information preferably does notcontain anything more than the name of the service and its descriptionand purpose. These are all the infrastructure services available to bedeployed.

[0115] The folder named “implementation services” contains all theimplementation packages that have been made available. Each of thesecontain the related metadata describing the service contract as well asthe binaries that contain the actual implementation of that servicecontract behavior. It is also possible to further group the serviceimplementations.

[0116] The folder named “deployment domains” contains the deploymentdomains underneath it. Each deployment domain can have a folder of itsown. Each deployment domain furthermore has one folder for each virtualcontainer in it. The folder for the virtual container all theinfrastructure services that it is configured with and all the hoststhat it is deployed on.

[0117] Active object identifier 540 shows which object is currentlyactive. Here, “Domain 1” is the active object; this label will change tocorrespond to whichever object the user is acting upon. This area isactually sensitive to whether a deployment domain is selected or avirtual container is selected.

[0118] Related objects area 520 shows all objects, grouped according totype, which are currently associated with the active object. In thisexample, because deployment domain “Domain 1” is the active objects, therelated objects area 520 shows all hosts, infrastructure services, andvirtual containers for business services that are currently deployed inDomain 1. In this example, both Host 1 and Host 2 are associated withDomain 1, and the Security and Package Tracking services are deployed inDomain 1.

[0119] Note that if, for example, “Host 1” were the active object 540,then the related objects area 520 would display all deployment domains,infrastructure services, and virtual containers related to Host 1.Whatever type of object is showing as the active object 540, the othertypes of objects will be show in the related objects area 540.

[0120] Finally, properties area 530 is used to define and modify theproperties for any object. When an object is selected anywhere in theuser interface 500, any customizable properties related to that objectwill be shown in properties area 530. The user may then edit theseproperties as appropriate.

[0121] Using interface 500, the user can select an active object 540,then drag and drop objects between the available objects 510 and therelated objects area 520. When an object is dragged from the availableobjects area 510 into the related objects area 520, the system will thenperform all necessary file generation and configuration, as defined bythe appropriate properties, to actually form the logical relationshipbetween the dropped object and the active object. This process isdescribed in more detail elsewhere in this disclosure, and theimplementation is within the abilities of one of skill in the art.

[0122] For example, if the “Online Catalog” service implementation weredragged into the related objects area 520 when the active object 540 is“Domain 1,” then the system will automatically generate all necessarybinaries, and transfer and install them as appropriate, to deploy theOnline Catalog service in the Domain 1 deployment domain.

[0123] In the same manner, if an object is dragged out of the relatedobjects area 520, then the system will remove its logical relationshipwith the active object.

[0124] Up to this level, the elements are those that exist in globalspace. These are elements or pieces of metadata that are not specific toa deployment domain. Further into the deployment domain, the metadatabecomes more specific.

[0125] One or more hosts can be prepared to host a deployment domain.Similarly, a single deployment domain can span multiple hosts. All thehosts configured for a specific deployment domain appear in the folderbelonging to that deployment domain. These nodes may contain data suchas the working area to store different deployment packages containingdifferent binaries and configuration files belonging to theinfrastructure as well as business services in that deployment domain.

[0126] An infrastructure service can be configured in multipledeployment domains and a single deployment domain will have multipleinfrastructure services. This relationship is similar to themany-to-many relationship that the hosts have to a deployment domain.When an infrastructure service is configured for a deployment domain,its related software, such as its plugins, is physically transferred toall the hosts that are configured for the domain.

[0127] When a new virtual service container is created, it is ready tobe deployed to any of the physical machines. Each container has a folderof its own underneath the deployment domain folder. The list of hoststhat appear here are the hosts where this container is physicallydeployed and the list of infrastructure services are the ones that hiscontainer is configured to use.

[0128] By organizing the information like this, a visual tool of thepreferred embodiment can use drag-and-drop capabilities to compose thevirtual service container.

[0129]FIG. 6 shows an exemplary virtual container represented on acanvas. In this figure, the larger outside cylinder is the virtualservice container 600. The smaller cylinders inside the larger onerepresent the plugins 610 for the infrastructure services. At the end ofthe chain is the business service implementation 620 that the virtualservice container is hosting. Using this representation, the user candrag and drop infrastructure services, configured for that domain, fromeither the tree structure or a graphical palette. Similarly, thecontainer can be dragged onto a host in that domain, thus triggering thephysical deployment.

[0130] Another feature is the unique customization of the use of theconfigured infrastructure properties through a system of propertysheets. When a virtual container is configured with an infrastructureservice, at that time the preferred embodiment loads the plug of theinfrastructure service and invokes the plug, providing it the emptycollection of property sheets. The plug responds by populating thiscollection with property sheets that contain properties that it isinterested in. The runtime system and the composition tools do not knowanything about these properties. One the plug has populated the propertycollections with properties specific to it, the composition toolspresents those properties in a property editor that allows the user toprovide unique values for those properties. These properties are thensaved with the other metadata and can be changed later on. Eachcollection contains one or more property sheets and each property sheetcontains one or more properties. This organization of properties allowsfor a more readable and understandable organization of the properties.

[0131] Another feature of the preferred embodiment is thecode-generation capability. Once a container has been configured, itsdefinition is complete. However, it is not yet ready to be physicallydeployed because it is only a definition at this point. However, sincenow the definition is complete, the user can select a target environmentsuch as .NET or an EJB server. Once the target environment has beenselected a code generation scheme can be selected to generate softwarecode that maps the definition of the virtual container to the computerfacilities offered by the underlying target platform. This code can thenbe compiled and linked with the runtime environment required by theplatform and a package is created.

[0132] Various color coding schemes can be used to describe the statethat the container is in. The possible stages identified includeconfigured, packaged, and deployed.

[0133] The code generation software can additionally generate smartproxies that perform the equivalent of the virtual service container forthe client. These smart proxies integrate the infrastructure services asdefined by the business service for the client. For example, a businessservice may require the client application to authenticate itselfagainst the security infrastructure service and send only theauthentication token to the business service. A smart proxy willretrieve the metadata for the client and invoke the infrastructuresconfigured for the virtual container that are relevant for the clientenvironment. These plugs can then prompt the client for any data thatthey might require and use the runtime environment to send that data tothe virtual container along with the rest of the request data.

[0134] Just as the virtual service container can be packaged into adistributable unit, the smart proxies can also be packaged into adistributable unit. These units can then be separately provided to thosewho are interested in building client applications to those businessservices.

[0135] Another feature of the preferred embodiment is softwareconfiguration capability. Once the code for the virtual servicecontainer has been generated, compiled, and packaged, the container canbe placed into a packaged state. At this point, a host can be dragged onthe container. This will cause the software configuration facility toperform separate steps:

[0136] It can transfer the deployment package that contains all therelated files to the target host machine;

[0137] These files can then be unpackaged on that machine by thisfacility automatically and placed into the specific directoriesstructure required by the underlying platform;

[0138] In the case of web services, the web server can be configured toknow about the web service. Similarly in case of an J2EE, the EJB servercan be configured to know about the service; and

[0139] The configuration files can be placed into the proper areas.

[0140] Once these steps have been performed, the virtual servicecontainer has been transformed into a physical service that can beinvoked.

[0141] At a later time, when updates are made available for either thebusiness service implementation or the infrastructure services plugs,the corresponding packages can be updated and these updates can bepropagated to all the machines where the physicial business services aredeployed.

[0142]FIG. 7 shows a flowchart of an exemplary process in accordancewith the preferred embodiment. In this process, the user accesses a userinterface and selects a deployment domain (step 705). The user thendrags an icon representing a host system into the deployment domain areadepicted on the user interface (step 710). In response, the host isassociated with that deployment domain and any other objects in thedeployment domain (labeled DD in figure, step 715).

[0143] The user drags an icon representing an infrastructure service(labeled IS in figure) into the deployment domain area depicted on theuser interface (step 720). In response, the infrastructure service isassociated with the deployment domain and any other objects within thedeployment domain (step 725).

[0144] The user drags an icon representing a service implementation(labeled SI in figure) into the deployment domain area depicted on theuser interface (step 730), thus starting the definition of a virtualcontainer, and optionally specifies properties for the virtual container(step 735). In response, the service implementation is associated withthe deployment domain and any other objects within the deployment domain(step 740).

[0145] The user then drags one or more infrastructure services fromwithin this domain onto the virtual container (labeled VC in figure,step 745), and optionally specifies the properties for theinfrastructure services (step 750). In response, the system associatesthis infrastructure service with the virtual container (step 755).

[0146] The system then evaluates any new or changed associations (step760). The system generates any code necessary to implement theassociations (step 765), and transmits and installs the generated codeas necessary (step 770). In this way, the user is able to fully managethe deployment domain, and to deploy and manage the hosts and serviceswithin it, all using a simple and intuitive user interface.

[0147] It should be noted that in the exemplary process described above,and other processes described herein, not all steps must be performed atany given time. Furthermore, many of the process steps described abovemay be performed in any order, or repeated, without changing the natureof the process or the advantages it provides.

[0148] It should also be noted, as discussed above, that a similarmethod can be used when a host or service is first selected, then otherservices, hosts, or a deployment domain is then associated with thathost or service using the drag-and-drop technique above. Similarly, theimplementing code will then be generated and installed by the system.

[0149] Configuration Architecture

[0150] The preferred embodiment provides extensive capabilities topackage software modules into packages, store packages in a masterlocation, transfer packages in and out of that master location andconfiguring any supported underlying platform for a web service.

[0151] Most conventional software configuration mechanisms deal withsoftware distribution on a desktop client. The preferred embodimentmanages software distribution of web services, including the softwarefor business service as well as the infrastructure services. It alsoconfigures the diverse underlying application server platforms such asMicrosoft .NET or BEA WebLogic. Using the disclosed system and methods,the users can manage the automatic distribution of web services in adistributed network, distribute software updates remotely andtransparently deploy that software on the underlying platforms.

[0152] The presently preferred system uses commonly available zip andcompression algorithms to package software modules and other relatedfiles. All packages, which may include programming language specificcode and binaries or platform specific assemblies are stored in the sameformat.

[0153] Core Package

[0154] One component of the preferred system is the runtime framework.Any infrastructure service plugs or business service implementation, orbusiness service containers require the binaries from the framework inorder to build successfully.

[0155] This package contains the core binaries of the framework. Thereis one such package for each supported language or compilation system.Initially, there may be multiple such packages, e.g., one for buildingthings in Microsoft's .NET environment, another for Java, and others forother virtual environments.

[0156] Infrastructure Service Package

[0157] The infrastructure services are integrated by writing plugs thatrepresent them in the system environment. These plugs are thendistributed to the machines from which these infrastructure services arebeing used. However, in addition to these plugs, the binaries associatedwith the infrastructure service itself also need to be distributed. Thispackage, one for each infrastructure service and for each compilationenvironment, includes the binary code for the software plug itself, aswell as the compilation environment specific binaries for theinfrastructure service.

[0158] Business Implementation Package

[0159] A service implementation package contains all the binariesrequired for the implementation of business logic. In case of .NET, thismay be a dynamic linking library (DLL) that contains the code for thebusiness service implementation and one or more DLLs required forcorrect linking and execution of the business logic implementation.Similarly for Java based platforms, the package may contain either oneor more class files or JAR files. A manifest file describes each ofthese binaries.

[0160] Deployment Package

[0161] A deployment package contains the code necessary for the physicalimplementation of the virtual container. It does not include the codefor the system framework itself or the infrastructure services or thebusiness service implementations. Those packages are not includedbecause they already exist in the vault separately and are copied onlywhen necessary.

[0162] Master Vault

[0163] Master vault is a machine in the entire network that serves asthe designated repository to store various packages during the entirelifecycle of the services. In a sense it is the file-server for thedisclosed platform. The work area for master vault is represented by atop-level directory.

[0164] Underneath the root of the work area, there is a sub-directoryfor all the available Hosts. There is a file for each of the hosts thatdescribes that host.

[0165] There is also a sub-directory for Service Implementations. Inthis sub-directory, each service implementation has a folder. In thisfolder, the raw metadata for the service, its contract definition andthe implementation packages are kept as files.

[0166] There is a directory for deployment domains here also. Thisdirectory contains separate directory for each deployment domain. Inthis deployment domain, all the software packages for the configuredbusiness services are kept.

[0167] The metadata describing each deployment domain and everythingunderneath resides in high performance servers that have a caching andfederation architecture for high performance and scalability.

[0168] Agents

[0169] An agent is a software service that runs on each machine. Onwindows based systems, this service can run as a Windows service and onnon-windows machines, it can run as a background process.

[0170] This service provides all the logic necessary for managing thevault and software configuration of the supported underlying platform.One machine can be designated as the Master Vault. The agent that runson that machine assumes the role of the master agent. This dualpersonality of the agents allows any machine to be designated as themaster vault. The master agent receives the requests for transfer ofsoftware packages into and out of the master vault. The master agentalso maintains a directory structure on the master vault for organizingvarious software packages. Depending upon the task to be performed, anagent may either perform the request itself or it may delegate therequest to the agent running on the master vault.

[0171] Configuration Process

[0172] The agents are responsible for correct configuration of theunderlying application services platform, with the least amount of inputfrom the user.

[0173] As new infrastructure services are available, various tools areused to create or update their packages. As mentioned before, thesepackages are distributed throughout the network, wherever the businessservices that use these infrastructures are deployed. That means thatthe system has to be able to propagate the updates throughout thenetwork when needed. This propagation process is coordinated by thetools provided by the environment.

[0174]FIG. 8 shows a process of this remote deployment and configurationof updated packages in accordance with a preferred embodiment of thepresent invention. Those of skill in the art will recognize that not allsteps are required to be performed in the order described and someembodiments may combine certain steps or reorder them without departingfrom the invention.

[0175] The system first determines which remote systems are running anenvironment that requires an updated infrastructure service (step 810).Next, the business services running on those remote machines in thenetwork are requested to pause their request processing (step 815).Next, the remote machines are requested to and will unload the existingsoftware package (step 820).

[0176] Next, the software agents are used to transfer the updatedpackage for the infrastructure service to that machine (step 825). Thepaused business service on each machine is then requested to reload theinfrastructure package (step 830). After they have done so, the businessservices on the remote systems will resume request processing using theupdated infrastructure services package (step 835). In this way, theinfrastructure services are updated with a very slight impact on theprocessing of the remote systems, and without having to “bring down” anysystems.

[0177] Packages for business service implementations are created andpropagated in similar manner.

[0178] Creation of deployment package in the system involves multiplesteps. First, an administrator uses system tools to configure a virtualcontainer for the business service. This container exists only inmetadata and is platform-neutral. The administrator then provides uniqueproperty values for fine-tuning. Next, the administrator selects aspecific underlying platform and generates code for the physicalcontainer (the web service). The code generators generate code for thatspecific container according to the pre-defined mappings of the virtualcontainer to the physical container. This code is then built andpackaged into platform-specific packages. As described, this packagedoes not need to include the package for the business serviceimplementation as well as the infrastructure services, since thisinformation is already available in the metadata.

[0179] When the administrator attempts to deploy the service to aspecific host, the agents first determine the supported platforms onthat machine. If multiple platforms are supported on that machine, thenthe user is prompted for the choice. Once the platform has beendetermined, the agent on the local machine collaborates with the masteragent to retrieve the correct deployment package, as well the packagefor business service implementation and packages for all the configuredinfrastructure services from the mater vault. The contents of thesepackages are then extracted and copied to a file structure that isspecific to the underlying platform. After that, the underlying platformitself is configured, e.g., Microsoft's IIS requires creation of avirtual directory while the J2EE platforms require modification ofserver configuration files.

[0180] Once this configuration is complete, the web service is ready toreceive request.

[0181] Self Configuration & Self Healing

[0182] The preferred embodiment operates on the principal of minimumconfiguration and self-healing. The system is able to detect its ownerrors and attempt to take necessary actions to correct itself.

[0183] Infrastructure Service Integration

[0184] One particular feature of the preferred embodiment is the abilityto integrate one or more infrastructure services with a business serviceto provide the desired level of support required for the correctoperation of the business service.

[0185] This support is provided in such a way so that the infrastructureis very flexible. This infrastructure can be continually enhanced byadding more infrastructure services, removing the outdated or deprecatedservices or by updating the existing services with new versions.

[0186] This kind of flexibility first of all allows a managedenvironment to take full advantage of the changing technologies andevolving standards and new products coming onto the marketplace. Thestrength of the architecture is in providing a framework for making 3rdparty products play in the disclosed environment rather than having tocustom write infrastructure services to do what commercially availableproducts already might do.

[0187] The infrastructure service integration capability also allows theservices to be updated. So for example, if the new version of a servicebecomes available and the plug for that service has to be updated, thearchitecture should allow that kind of update as well.

[0188] The metadata that describes an infrastructure service consists ofinformation required to load a service plug, properties that it isinterested in and information necessary to determine whether the plughas relevance to client-side, server-side or both.

[0189] The information necessary for loading the plug dynamically issomewhat specific to the platform environment. For example, .NETenvironment would require the assembly that the plug is in and the nameof the class that implements the plug interface.

[0190] The most important metadata for an infrastructure service,according to the presently preferred embodiment, is in the form of aproperty sheet collection. A property sheet collection contains one ormore named property sheets. Each property sheet contains a set ofrelated properties that the plug needs to tune its behavior for aspecific usage. Each plug by default has a property sheet named“General” that contains some basic properties. These properties indicatewhether the plug processes incoming messages or outgoing messages orboth and whether it participates in the code generation process. Defaultvalues are assigned to these properties.

[0191] Later, when a business service virtual container is configured touse this infrastructure service, the plug for this infrastructureservice is invoked and it adds specific properties to the property sheetcollection.

[0192] The following table is an exemplary property sheet for a possiblesecurity service: Sheet Name Property Name Property Value GeneralProcess Incoming Messages true Process Outgoing Messages true GenerateCode false Authentication Authentication Required true AuthenticationType Service Based Authentication Authentication Domain domain.comAuthorization Authorization Required true Authorization Resourcehttp://someresource.com Role Based Permission true Role Namespacecorporate Role Property roles Operation Domain DemoOps EncryptionEncrypt Messages false Properties Encryption Type Symmetric EncryptionEncryption Method Signature Signature Required False PropertiesSignature Method

[0193] This collection has 5 sheets that provide sets of propertiesrelated to each other. This allows the plug to have multiple propertieswith the same name but in different sheets. Various parts of the plugsruntime can retrieve these properties and use them as needed.

[0194] The metadata also describes whether a particular infrastructureservice acts only on the server side or the client side or both. Itfurther indicates whether the infrastructure service need to participatein the code generation process to provide code that is specific to it.

[0195] Plug-and-Play Integration

[0196] Each infrastructure service is represented in the systemenvironment through a system plug interface. This plug represents aninfrastructure service in the environment. The preferred embodimentitself does not differentiate between a specific kind of infrastructureservice (e.g. it does not differentiate a security service from thetransaction service). To this system, all infrastructure services appearthe same and it invokes them at the right points during the messageprocessing. A message processing model, for example, makes it possibleto write service implementations and client programs that haveabsolutely zero knowledge of what infrastructure services are executing,what inputs do they require and what kind of extra information needs tobe inserted in the messages or extracted from them for the correctoperation. The service plugs therefore perform all that logic themselvesin a completely encapsulated manner.

[0197] If an infrastructure service is a simple service and isimplemented in terms of a library, the plug would wrap that service andthe service would be invoked inline. However, most sophisticatedinfrastructure services are standalone third-party services. Forexample, a security service may have a separate service process that mayperform authentication and authorization. For those kinds of services,the plug actually acts on behalf of the remote service inside thetool-time or runtime environment.

[0198] The system runtime defines an abstract interface known asServiceHandler interface. A plug for an infrastructure service first hasto implement this interface.

[0199] Initializing for Use

[0200] In this environment, an infrastructure service has nosignificance or identity until it is selected to be integrated inside abusiness service virtual container, and the metadata for aninfrastructure service is mostly undefined until this point. However,when a user uses the composer tool to drag and drop an infrastructureservice on a business service virtual container, the plug for theservice is loaded in at that time and this method is invoked on the plugand the empty metadata container is passed to it.

[0201] In response, the plug populates the metadata with a set ofproperties. The properties are represented generically and relatedproperties are organized into sheets for easy organization,traverse-ability and presentation. The plugs then populate the metadatawith only those properties that are required by it to provide the properbehavior at runtime when it is invoked.

[0202] There are a few general properties that all plugs have and thesystem provides some default values for those properties. For example,by default, a property is added to the property sheet marked “General”that indicates that this plug does not participate in the codegeneration process. A plug may also override such properties at thistime.

[0203] In addition to manipulating this property sheets collection, theplugs may also modify other pieces of metadata. For example, by defaultall plugs are marked as service-side as well as client-side plugs. Thismeans that these plugs will be loaded and invoked by the runtime,regardless of whether it is in the client-side or server-side. However,for some plugs, it does not make sense to do that on the client-side.For example, for collection of service metrics, the plug of themonitoring service only needs to be invoked on the service-side. Hencethis plug does not need to be distributed, loaded and invoked on theclient-side. The plug can again override these values at this time too.

[0204] Once this method has successfully modified the metadata, thismetadata can then be saved in the metadata server.

[0205] Initialize For Runtime

[0206] This method is invoked by the runtime when it loads the plug intothe runtime for business service virtual container. At this time theplug can initialize tits internal data structures, allocate anyresources that it needs to, and cache the needed metadata.

[0207] For example, if the plug represents a remote service then itwould need to establish a connection with that service in order tocommunicate with it. Instead of opening that connection every time, theplug may need to open the connection in this method upfront and use itwhenever needed.

[0208] Invoke

[0209] When the business service virtual container receives a servicerequest, it invokes all the loaded plugs by calling this method on them.Two of the arguments to this method are the parameters that wereprovided with the requests, or in case of a response the responsevalues, and the direction of the request. The direction of the requestindicates whether this request is incoming or outgoing. The thirdparameter is the context of the request and has many pieces ofinformation.

[0210] Since the plug interface does not differentiate methods requiredfor client-side vs. server side and incoming vs. outgoing, the directionparameter allows determination of the direction and the context can betype-casted to either a ServiceContext or ClientContext to determinewhether the plug is being invoked on the server-side or client-side.

[0211] Generate Configuration Code

[0212] Code generation process is described explained in detail belowand elsewhere in this application, to the extent necessary to enable oneof skill in the art to replicate the claimed inventions. Simply put,there is a strong need to provide the plugs with the opportunity ofgetting involved in the code generation process. If a plug has indicatedthat it does want that participation then this method is invoked to letthe plug modify the configuration code to be generated by possiblyadding its own specific code.

[0213] Generate Server Code

[0214] This method allows the plug to insert the code that might beessential for its operation on the service-side. The programming codeitself is represented in XML and the plug adds to that XML. Later, thecode generator converts that XML back to the programming languagespecific code.

[0215] Generate Client Proxy Code

[0216] This is similar to the above method except that it augments thecode that makes up the client proxy. This is invoked only for thoseplugs that are client-side plugs.

[0217] Service Packaging

[0218] An infrastructure plug has executable code associated with it. Inaddition to the actual implementation of the plug interface for thisinfrastructure service, the binaries associated with the remote servicemight also be required. All of these need to be in the appropriatedirectories on the machines where the business service is executing.

[0219] System administration tools allow creation of packages for theseinfrastructure services. These packages are then placed in the mastervault so that they can be copied to any machine for correct deployment.

[0220] Business Service Virtual Container

[0221] One significant feature of the disclosed system environment isits ability to provide a very configurable and dynamic runtime executionenvironment that a) provides a host for the business serviceimplementation and b) integrates it with one or more infrastructurelevel services that are needed for its correct operation.

[0222] The construct for accomplishing that is the Business ServiceVirtual Container. This container is called virtual because it existsonly in metadata definition. Furthermore, this definition is independentof any underlying platform.

[0223] The system then defines mappings of this virtual container to thephysical containers for all supported underlying platform environment.Once these mappings have been defined, code can be automaticallygenerated to produce the physical container from the virtual container.

[0224] The code for the physical container produced by the codegenerators is then compiled and linked with all the related binaries forthe business service implementation as well as all the binaries forrequired infrastructure services. This is the code that can actually bedeployed to an underlying platform environment and has a physicaladdress and receive requests.

[0225] Just like the physical container generated from this metadataprovides the execution environment for the service itself, physical codecan also be generated for the client side proxies that are smart enoughto interpret the metadata properly and can load and execute serviceplugs for correct usage of the infrastructure services. These areexplained in more detail below.

[0226] Runtime Framework

[0227] The runtime framework is a lightweight framework that providesthe mechanisms hosting a business service implementation and allowingthat hosted service to also leverage capabilities offered by one or moreexisting infrastructure services.

[0228] On the client-side, the framework processes the request throughthe plugs configured for the target service. In doing this, only thoseplugs are processed that have relevance to the client environment. Oncethis processing finishes, the request is then dispatched to the actualtarget service via its proxy. The response is again processed throughthe service plugs before it is returned back to the clientimplementation.

[0229] On the server-side, this framework transparently intercepts allincoming requests and processes those requests through the configuredplugs for this virtual container. Once all those plugs have beenprocessed, the service request is dispatched to the actual serviceimplementation. Once that request finishes, the response is processedthrough all the necessary plugs and eventually forwarded back to theinvoking client.

[0230] In addition to managing the invocation of the related serviceplugs, the framework also provides extensive logging capabilities. Theproperties related to logging levels can be modified on-the-fly withoutany need to stop and restart applications.

[0231] The client-side and the server-side components of the frameworkseparate the client implementation and the service implementation fromthe infrastructure capabilities completely. This actually allows theframework to provide various levels of quality of service such asreliable delivery and asynchronous reliable delivery. These capabilitiescan be customized for each virtual container.

[0232] Deployment Domains

[0233] The preferred embodiment provides mechanisms to partition a largeIT environment into smaller logical partitions so that they can beconfigured with a set of infrastructure capabilities. Business servicesare deployed in a deployment domain. Generally, a set of relatedapplications would be deployed in the same deployment domain. Thisdeployment domain would be configured with a set of infrastructureservices necessary for the quality of service desired.

[0234] A deployment domain consists of one or more hosts. These hostscollectively define the logical boundary of the deployment domain. Anybusiness services that are part of this domain can be deployed on any ofthe hosts in that are part of that domain.

[0235] A deployment domain also consists of one or more infrastructureservices that in turn come from the list of globally availableinfrastructure services. The significance of this subset ofinfrastructures services is to control visibility of the infrastructureservices further and provide easy configuration of the business servicecontainers.

[0236] Lastly, a deployment domain consists of one or more businessservice containers created in that domain. These container can then beconfigured with one or more infrastructure services, thoseinfrastructure services can be customized, code for physical containerbe generated and the services can be deployed.

[0237] Service Contexts

[0238] A service context carries with it the necessary information thatis required to process a request as well as general information that iscommon the environment. Service context in initialized once and thencached. If the service receives notification of changed metadata, thenthe service context can be re-initialized.

[0239] Client Context

[0240] This context is initialized for the client's runtime. Itinitializes the metadata for the client, creates the pipeline for therequired plugs for the client and also initializes the logging mechanismfor the client.

[0241] Service Context

[0242] This context accomplishes the same for the server-side runtimeenvironment. One of uses of these contexts are also to determine whethera particular piece of code is executing in the client environment or theserver environment. While they both derive from the class Context theycan be typecasted to either one of the derived class instances in orderto decide.

[0243] Loading Service Plugs

[0244] When a service starts, its metadata is retrieved and processed.An important part of this processing is to load the plugs for all theinfrastructure services that the business service is configured with.Once these plugs have been loaded dynamically, they are organized into alinear pipeline and all the incoming messages are processed through thatpipeline. The order of the plugs in the pipeline is the same as theorder in which they appear in the composition environment. This order isimportant because the messages need to be processed like that. Forexample, if a security service needs to decrypt an incoming message, itis important that this service is the first one in the pipeline becauseotherwise the parameters might not make any sense to other services.Similarly, if metrics may need to collected about this service, it isimportant that those are taken last in the pipeline so that processingtime for the other service plugs is not accounted for in the metrics forthe actual business processing of the request.

[0245] These plugs are loaded in such a way so that they can be unloadedand reloaded without bringing the application down. So for example, in.NET these plugs are loaded in separate application domains. This isimportant because the preferred system allows dynamic configuration andreconfiguration and software updates. This is evident from the followingexemplary scenarios:

[0246] 1. A business service is configured with a new infrastructureservice. The Composer tool modifies the metadata, copies the packagecontents for the new infrastructure service into the appropriatedirectories of the hosts that the business service is deployed on andthen informs the business service container for the change. Businessservice container can then load the plug for the newly configuredservice and insert it in the appropriate place in the pipeline.

[0247] 2. An infrastructure service is removed from the configuration ofa business service. The Composer tool removes the plug from the metadataand removes the binaries from the appropriate directories from thedeployed hosts. The business service is then informed which then unloadsthe plug and removes it from the pipeline.

[0248] 3. A new version of the infrastructure service is made available.The Composer tool copies the new package to the appropriate hosts, thebinaries are copied to the appropriate directories and the businessservice is informed, which then reloads the package for that service.

[0249] When a request now comes in, it is received by the businessservice container. This container invokes the plug for eachinfrastructure in the same order as they appear in the pipeline. Thenext plug is invoked if the previous plug is successful. The processingstops whenever a plug is unable to invoke successfully.

[0250] This kind of plug architecture allows the business serviceimplementations to be completely devoid of any logic that relates to theinfrastructure services thus making it possible to completely replacethe infrastructure services and underlying products without effectingthe service implementations or flow of business requests at all.

[0251] Managed Container Interface

[0252] The system container generates the shell skeleton of a businessservice implementation. These derive from the class ManagedContainerfrom the runtime framework. This managed container provides theimplementation of many of the methods that are necessary entry pointsinto the runtime framework.

[0253] When a service starts up, an instance of this class is created.This container initializes the appropriate context. Once the metadatahas been initialized, the container caches it. Some of the importantmethods are discussed below.

[0254] Metadata Refresh

[0255] When a business service receives a request to re-initialize itsmetadata because it has changed, this method clears the metadata cache,unloads all the loaded plugs and then re-initializes the metadata, thusrebuilding the plug processing pipeline. By providing this methodthrough the managed container, services can be reconfigured without theneed to stop and restart them.

[0256] Logging Levels

[0257] Through these tools, the logging levels of the logging mechanismcan be changed. This method changes the logging level on-the-fly.

[0258] Get and Set Application Data

[0259] Most underlying web services platforms allow the applications toexecute in a multi-threaded environment, processing multiple calls atthe same time in separate threads. ManagedContainer allows applicationsto store named sets of data in a thread-safe manner instead of savingthe state information in local variables in un-safe manner.

[0260] Smart Proxies

[0261] Smart proxies provide an environment for the client-side codethat performs the same kind of processing as performed by the runtime onthe server-side in the virtual container. The smart proxies sit abovethe proxies that might be generated by tools such as Microsoft .NETplatform, and uses those proxies. When a client application instantiatesa smart proxy, the proxy retrieves the metadata for the target webservice and for performance caches it. It then constructs a pipeline ofplugs that the target service is configured with in the same manner thatthe server runtime does. However, only those handlers are configuredthat are relevant to the client.

[0262] Once this pipeline has been constructed, all requests areprocessed through this pipeline. This kind of processing completelyseparates the implementation of the actual client from the processing ofthe infrastructure service code. So for example, the plug for a securityservice may prompt the client for the necessary user credentials andpackage them appropriately for transmission to the server side. They mayalso encrypt messages or sign them as necessary. A replacement of thissecurity with a different one would mean that their plugs are replacedand the new plug may prompt the user for different kind of information.Again, the client implementation would not rally care and know about allthat.

[0263] Smart proxies may also be specialized by the intelligent codegeneration process. The plugs for a load-balancing service might insertcode for making load-balancing decision in the smart proxy itself duringthe request processing.

[0264] Those skilled in the art will recognize that, for simplicity andclarity, the full structure and operation of all data processing systemssuitable for use with the present invention is not being depicted ordescribed herein. Instead, only so much of a data processing system asis unique to the present invention or necessary for an understanding ofthe present invention is depicted and described. The remainder of theconstruction and operation of data processing system may conform to anyof the various current implementations and practices known in the art,and unless otherwise noted herein, those of skill in the art willrecognize that any claimed features of a data processing system can beimplemented using conventional data processing system and dataprocessing system network hardware, configured and programmed to operateas claimed and described. In particular, any steps of describedprocesses can be implemented using known data processing system means.

[0265] It is important to note that while the present invention has beendescribed in the context of a fully functional system, those skilled inthe art will appreciate that at least portions of the mechanism of thepresent invention are capable of being distributed in the form ofinstructions contained within a machine usable medium in any of avariety of forms, and that the present invention applies equallyregardless of the particular type of instruction or signal bearingmedium utilized to actually carry out the distribution. Examples ofmachine usable mediums include: nonvolatile, hard-coded type mediumssuch as read only memories (ROMs) or erasable, electrically programmableread only memories (EEPROMs), user-recordable type mediums such asfloppy disks, hard disk drives and compact disk read only memories(CD-ROMs) or digital versatile disks (DVDs), and transmission typemediums such as digital and analog communication links.

[0266] Although an exemplary embodiment of the present invention hasbeen described in detail, those skilled in the art will understand thatvarious changes, substitutions, variations, and improvements of theinvention disclosed herein may be made without departing from the spiritand scope of the invention in its broadest form.

[0267] None of the description in the present application should be readas implying that any particular element, step, or function is anessential element which must be included in the claim scope: THE SCOPEOF PATENTED SUBJECT MATTER IS DEFINED ONLY BY THE ALLOWED CLAIMS.Moreover, none of these claims are intended to invoke paragraph six of35 USC §112 unless the exact words “means for” are followed by aparticiple.

What is claimed is:
 1. A method for managing services, comprising:identifying at least one remote system; sending a request to the remotesystem to pause processing of at least one system service; sending anupdated software package to the remote system; and sending, to theremote system, a request to install the updated software package,wherein the remote system thereafter resumes the processing of thesystem service, using the updated software package.
 2. The method ofclaim 1, wherein the system service is an infrastructure service.
 3. Themethod of claim 1, wherein the system service is a business service. 4.The method of claim 1, wherein the updated software package includesadditional software services which are not already installed on theremote system.
 5. The method of. Claim 1, wherein the remote systemunloads an existing software package after pausing processing.
 6. Themethod of claim 1, further comprising receiving an instruction from auser to update software packages on remote systems.
 7. The method ofclaim 1, wherein updated software packages are sent to multiple remotesystems simultaneously.
 8. A data processing system having at least aprocessing and an accessible memory, comprising: means for identifyingat least one remote system; means for sending a request to the remotesystem to pause processing of at least one system service; means forsending an updated software package to the remote system; and means forsending, to the remote system, a request to install the updated softwarepackage, wherein the remote system thereafter resumes the processing ofthe system service, using the updated software package.
 9. The dataprocessing system of claim 8, wherein the system service is aninfrastructure service.
 10. The data processing system of claim 8,wherein the system service is a business service.
 11. The dataprocessing system of claim 8, wherein the updated software packageincludes additional software services which are not already installed onthe remote system.
 12. The data processing system of claim 8, whereinthe remote system unloads an existing software package after pausingprocessing.
 13. The data processing system of claim 8, furthercomprising means for receiving an instruction from a user to updatesoftware packages on remote systems.
 14. The data processing system ofclaim 8, wherein updated software packages are sent to multiple remotesystems simultaneously.
 15. A computer program product tangibly embodiedin a computer-readable medium, comprising: instructions for identifyingat least one remote system; instructions for sending a request to theremote system to pause processing of at least one system service;instructions for sending an updated software package to the remotesystem; and instructions for sending, to the remote system, a request toinstall the updated software package, wherein the remote systemthereafter resumes the processing of the system service, using theupdated software package.
 16. The computer program product of claim 15,wherein the system service is an infrastructure service.
 17. Thecomputer program product of claim 15, wherein the system service is abusiness service.
 18. The computer program product of claim 15, whereinthe updated software package includes additional software services whichare not already installed on the remote system.
 19. The computer programproduct of claim 15, wherein the remote system unloads an existingsoftware package after pausing processing.
 20. The computer programproduct of claim 15, further comprising instructions for receiving aninstruction from a user to update software packages on remote systems.21. The computer program product of claim 15, wherein updated softwarepackages are sent to multiple remote systems simultaneously.
 22. Amethod for managing services, comprising: identifying at least oneremote system; sending a software package to the remote system; andsending, to the remote system, configuration information for thesoftware package, wherein the remote system thereafter installs andconfigures the software package, using the configuration information.